Non-persistent virtual desktop infrastructure (VDI) designs create a pool of virtual desktops and assign users dynamically to any available machine in the pool at the point when users make a request for a remote session. Non-persistent VDI designs (e.g., “pools”) direct users to random virtual machines (VMs), each time resulting in a new machine identity each time. Some software does not function properly in this context because it checks for a stable machine identity for licensing or security reasons. User installed applications that may be preserved using layering technology could lead to installation of applications that expect a stable machine identity at each application launch.
For example, certain classes of software fail to function properly within these VDI designs because they expect a stable machine identity. Other types of software insist on seeing a stable and static machine name for licensing reasons and will embed the name of the machine on which they were originally installed into the Registry or other configuration file, and check it at each application launch to validate that it is running on the same machine.
Some non-persistent designs cannot accommodate such software, and users needing these types of applications would need to be assigned to persistent virtual desktop. Some existing non-persistent VDI designs do not accommodate the installation of applications by users themselves. The desktops are typically ‘locked-down’ from a security standpoint which prevent such installations and there is no way to preserve user changes across linked-clone ‘recompose’ operations anyway.
Some systems use layering technology to preserve user-state across linked-clone pool operations such as recompose/refresh/rebalance, including any user installed applications (UIA) such as AppVolumes by VMware, Inc. These layering approaches retain the storage efficiency enabled by linked-clone based non-persistent designs while offering persistent design functionality to users.
However, the UIA capability available to non-persistent designs also introduces some compatibility risks. Whereas previously, the administrator was in a position to place users on the appropriate type of VDI desktop based on what type of applications they needed and whether their applications required a persistent machine identity, in the UIA enabled non-persistent designs it is entirely possible for users to themselves install an application of the type requiring a persistent machine identity and find out upon their next VDI login that the installed application won't function and throws errors related to the changed machine name of the new VM on which the user is placed.